1. Field of the Invention
The present invention relates to a method of setting bidirectional path, and a communication system and a node device for providing the setting method, and in particular, to a method for setting a bidirectional path between nodes in a network which supports MPLS (Multi Protocol Label Switching) protocol, and a communication system and a node device for providing the setting method.
2. Description of the Related Art
There is RSVP-TE (Resource reSerVation Protocol-Traffic Engineering) defined by IETF RFC3209 (which can be downloaded from URL [http://www.ietf.org/rfc/rfc3209.txt]) as a protocol for dynamically performing label distribution between devices in order to set up (establish) a path (LSP: Label Switch Path) in MPLS. In the RSVP-TE, a path message (Path) corresponding to a requirement of LSP setup is sent from an Ingress node to an Egress node and a label for transfer is returned in the backward direction by using a reserve message (Resv) to setup a LPS as shown in FIG. 1. As shown in FIG. 1, when communication is performed between two bases (nodes) #1, #3 in bidirectional directions, LSP's 14, 16 are respectively independently set up by signaling 10, 12 in each direction of Node#1 (Ingress) to Node#3 (Egress) and Node#3 (Ingress) to Node#1 (Egress). In FIG. 1, signaling 10 for setting a path in the direction of Node#1 (Ingress) to Node#3 (Egress) is denoted by a sign #13, and signaling 12 for setting a path in the direction of Node#3 (Ingress) to Node#1 (Egress) is denoted by a sign #31. Herein, the timings of setup of the LSP's 14, 16 are respectively independent and the routes thereof are not necessarily the same as shown in FIG. 1. This is because each of the nodes #1, #2, and #3 independently selects a route in accordance with a usage status of the bandwidth when setting up a LSP.
Pseudo Wire is a technology for connecting two nodes by a pseudo wire by using the MPLS. The pseudo wire is a path established in bidirectional directions by which data of all sorts of protocols such as SONET/WDM, ATM, frame relay, or the like can be carried. In this case, as in the conventional SONET/WDM, it is desirable that the paths connecting two bases are the same route and the timings of setup are also the same for network administration. The reason is because, it is easier for an operator to understand and to figure out when data passes the same route than when data passes discrete routes, and only one operation is required when the timings of setup are the same.
However, RSVP-TE is generally used for a label distribution protocol for setting MPLS LSP for leading the Pseudo Wire. Accordingly, there is no assurance that a forward and a backward LSP's pass the same route between two bases. Further, setup timings of LSP's are independent. Accordingly, there is a problem in that administration becomes complicated.
It is possible to set a bidirectional LSP by the same route by explicitly specifying the route by using Explicit Route Object (ERO). However, a forward LSP and a backward LSP are independent, so that there is no association between timings of setup. For example, it is possible to set up a backward LSP after setting a forward LSP by hand. However, it is impossible to automatically set up a forward LSP and a backward LSP. Further, as for the route, administration by a person is required in order to set two LSP's to the same route.
There is RSVP-TE (IETF RFC3473) extended for G(General)MPLS as a technique for setting up LSP's by the same route at the same time. IETF RFC3473 can be downloaded from URL [http://www.ietf.org/rfc/rfc3473.txt]. This is one in which Upstream Label object and the like are newly added and extended with respect to the above RSVP-TE of RFC3209. In the GMPLS RSVP-TE, as shown in FIG. 2, it becomes possible to setup a bidirectional LSP by only reciprocating a Path/Resv message by adding an Upstream Label object (ULO) to a path message (#13-Path with ULO in FIG. 2) and distributing a label for a backward LSP with the path message. Note that a label for the forward LSP is distributed with a reserve message (#13-Resv+LO in FIG. 2) as before.
However, when the Object is received by a node in which MPLS RSVP-TE is supported and GMPLS RSVP-TE is not supported, the Object can not be understood to be destroyed. Accordingly, there is a problem in that all of the nodes in a domain have to be extended to the GMPLS RSVP-TE in order to provide a bidirectional LSP.